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SYSTEM AND METHOD FOR GENERATING AND EXECUTING INSURANCE 
POLICIES FOR FOREIGN EXCHANGE LOSSES 

BACKGROUND OF THE INVENTION 
The present invention relates generally to 
5 foreign currency exchange, and more particularly to 

generating and executing insurance policies for foreign 
exchange losses. 

Rapidly expanding global commerce and 
international travel have dramatically increased the need 
10 for foreign currency exchange. Foreign exchange rates are 
highly variable, and numerous factors influence the 
exchange rates, such as economic strength of countries, 
political stability, countries' transnational policies and 
relationships, and demand for foreign currency. Due to 
15 high variability and numerous factors influencing the 
exchange rates, it is extremely difficult to predict 
future exchange rates even for a short period. 

Due to the unpredictable nature of the exchange 
rates, individual travelers may wish to lock in a 
20 favorable exchange rate before they travel to foreign 

countries, thus eliminating the need to purchase foreign 
currencies in advance. One way to protect against 
unpredictable fluctuation of exchange rates are forward 
currency contracts. These contracts give the buyer a 
25 right to purchase a certain amount of foreign currency at 
a specific price at a specific future time. Essentially, 
the buyer of the contract pays a premium for the right to 
purchase a large block of foreign currency at a fixed 
exchange rate. 

30 Unfortunately, forward currency contracts 

involve large sums of money, and thus, are practical only 
for large institutions and international companies seeking 
to minimize currency exchange risks, or commercial 
currency traders. The size of forward currency contracts 

35 generally does not vary, nor can they be shared by a group 



wo 98/21680 



PCT/US97/20754 



o 

of individuals. Additionally, there is little or no 
flexibility in specifying a range of coverage because 
forward currency contracts must designate a specific date. 

Accordingly, not only are these options 
restrictive, they do not offer avenues for individual 
5 consumers to hedge their personal currency risk. Instead, 
if individuals want to "lock in" a prevailing exchange 
rate, they must either purchase the foreign currency or an 
instrument denominated in the foreign currency, such as 
traveler's checks. The actual purchase, however, poses 
10 many disadvantages such as tying up funds, paying a 

commission, and foregoing the possibility of enjoying any 
favorable future fluctuations. 

Therefore, it is desirable to provide a method 
of protecting individual consumers against unpredictable 
15 fluctuations of foreign exchange rates. 

It is also desirable to offer a more flexible 
method for large entities to ensure against currency 
fluctuations . 

It is further desirable to provide a method of 
20 foreign currency exchange rate protection through commonly 
accessible means such as credit cards or ATMs. 

SUMMARY OF THE INVENTION 
Accordingly, the present invention involves 
generating and executing insurance policies for foreign 
25 exchange losses that substantially obviate one or more of 
these limitations by automatically determining an 
appropriate premium, and processing transactions under the 
foreign exchange insurance policies. 

Specifically, a method of providing a foreign 
30 exchange insurance policy consistent with this invention 
comprises a central controller receiving policy 
requirements from a user for the foreign exchange 
insurance policy; storing the policy requirements and the 
corresponding user id; accessing data corresponding to the 
35 specified currency and current market conditions; 
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estimating currency volatility from the accessed data; and 
computing a premium cost based on the currency volatility. 
The received policy requirements further include the 
specified currency, exchange rate, amount of coverage, and 
a period of coverage , 
5 According to another aspect of the present 

invention, a system for providing a foreign exchange 
insurance policy consistent with this invention comprises 
receiving means, a database, accessing means, estimating 
means, and computing means • The receiving means receives 

10 policy requirements from a user for the foreign exchange 
insurance policy, including a user id, a specified 
currency, exchange rate, amount of coverage, and a period 
of coverage. The database stores the policy requirements 
and the corresponding user id. The accessing means access 

15 data including historic exchange rates corresponding to 

the specified currency and current market conditions. The 
estimating means estimates currency volatility from the 
accessed data. Finally, the computing means computes a 
premium cost based on the currency volatility. 

20 BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings, which are 
incorporated in and constitute a part of this 
specification, illustrate the invention and together with 
the description, serve to explain the principles of the 

25 invention. 

Fig. 1 is a block diagram of a system consistent 
with the present invention; 

Fig. 2 is a detailed block diagram of the 
central controller in Fig. 1; 
30 Fig. 2A-2C are tables illustrating the data 

structure of the databases; 

Fig. 3 is a block diagram of another system 
consistent with the present invention using credit cards; 

Fig. 4 is a block diagram of yet another system 
35 consistent with the present invention using automatic 
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teller machines (ATMs) ; 

Fig, 5 is a block diagram of still another 
system consistent with the present invention using banks; 

Fig* 6 is a flowchart illustrating a preferred 
process for selecting policy requirements; 
5 Fig, 7 is a flowchart illustrating a preferred 

process for calculating an insurance premium; 

Fig. 8 is a flowchart illustrating a preferred 
process for creating the insurance premium for the user; 

Fig. 9 is a flowchart illustrating a preferred 
10 process for system maintenance of active insurance 
policies ; 

Fig. 10 is a flowchart illustrating a preferred 
process for transmitting transaction data using credit 
cards ; 

15 Fig. 11 is a flowchart illustrating a preferred 

process for determining whether an insurance adjustment is 
necessary for the process of Fig. 10; 

Fig. 12 is a flowchart illustrating a preferred 
process for calculating the amount of the insurance 
20 ad j us tment ; 

Fig. 13 is a flowchart illustrating a preferred 
process for transmitting transaction data using ATMs; 

Fig. 14 is a flowchart illustrating a preferred 
process for determining whether an insurance adjustment is 
25 necessary for the process of Fig. 13; 

Fig. 15 is a flowchart illustrating a preferred 
process for calculating the amount of the insurance 
adjustment for the process of Fig. 13; 

Fig. 16 is a flowchart illustrating a preferred 
30 process for transmitting transaction data using banks; 

Fig. 17 is a flowchart illustrating a preferred 
process for determining whether an insurance adjustment is 
necessary for the process of Fig. 16; 

Fig. 18 is a flowchart illustrating an 
35 authentication procedure using symmetric key protocols; 
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and 

Fig, 19 is a flowchart illustrating an 
authentication procedure using public key protocols. 

DETAILED DESCRIPTION 
Reference will now be made in detail to the 
^ present preferred embodiments of the invention, examples 
of which are illustrated in the accompanying drawings. 
System Architecture 

As shown in Fig. 1, a system consistent with the 
present invention includes a central controller 200, an 
10 end-user interface 300, and a transaction interface 400. 

The elements preferably connect to each other via a public 
switched telephone network. Alternatively, the system 
elements may be connected by dedicated data lines, 
cellular. Personal Communication Systems ("PCS"), 
15 microwave, satellite networks, Internet, or any other 

suitable form of data communications. Policy requirements 
50, insurance policy 60, and transaction data 70 travel 
through these connections. 

Fig. 2 shows a detailed block diagram of central 
20 controller 200 shown in Fig. 1. Central controller 200 

preferably includes a central processor unit (CPU) 205, a 
cryptographic processor 210, a random access memory (RAM) 
215, a read-only memory (ROM) 22 0, an Interactive Voice 
Response Unit (IVRU) 225, a payment processor 23 0, a clock 
25 235, an operating system 240, a network interface 245, and 
a data storage device 250. All of these elements are 
connected to CPU 205 to facilitate communication between 
them. 

Central controller 2 00 operates as a primary 
30 server, both receiving and transmitting communications 

with end-user interface 300 and transaction interface 400. 
Central controller 200 is preferably capable of high 
volume processing, performing a significant number of 
mathematical calculations in processing communications and 
35 database searches. Central controller 200 may be a 
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conventional personal computer or a computer workstation 
with sufficient memory and processing capability. For 
example, a Pentium* microprocessor such as the 100 MHZ 
P54C, commonly manufactured by Intel, Inc., may be used 
for CPU 205. This processor employs a 32 -bit 
^ architecture. Equivalent processors include the Motorola 
120 MHZ PowerPC 604 or Sun Microsystem's 166 MHZ 
UltraSPARC- I. 

Cryptographic processor 210 supports the 
encoding and decoding of communications as well as the 

10 authentication of transactions. A MC68HC16 

microcontroller, commonly manufactured by Motorola, Inc., 
may be used for cryptographic processor 210. This 
microcontroller uses a 16-bit multiply- and- accumulate 
instruction in a 16 MHZ configuration and requires less 

15 than one second to perform a 512 -bit RSA private key 

operation. One skilled in the art may easily substitute 
other commercially available, specialized cryptographic 
processors such as VLSI Technology's 33MHZ 6868 or 
Semaphore Communications' 40 MHZ Roadrunner2 84 . 

20 Alternatively, cryptographic processor 210 may be 
configured as part of CPU 205. 

Operating system 24 0 comprises a conventional 
operating system such as DOS, Windows, or 0S2 , 

Payment processor 230 supports the transfer and 

25 exchange of payments, charges, or debits. Exemplary 

services operable on payment processor 32 0 include on-line 
credit authorizations, credit card settlement, payments to 
transaction networks, and payment aggregation. 
Commercially available software, such as the Secure 

30 Webserver manufactured by Open Market, Inc., may support 
credit card transaction processing of payment processor 
230. This server software transmits credit card numbers 
electronically over the Internet to servers located at the 
Open Market headquarters, which handles card verification 

35 and processing. The Open Market's Integrated Commerce 
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Service provides back- office services necessary to run 
Web-based businesses. Payment processor 230 preferably 
comprises a microprocessor (such as the Intel Pentium®) , 
but alternatively may be configured as part of CPU 205. 

Operating system 240 comprises a conventional 
^ operating system such as DOS, Windows, or 0S2 . 

Data storage device 25 0 may include a hard 
magnetic disk, optical storage units, CD-ROM drives, or 
flash memory. Data storage device 2 50 contains databases 
used in processing transactions in the present invention, 

10 including an end-user database 255, a policy requirements 
database 260, an insurance policy database 265, a 
transaction data database 270, an exchange rate database 
275, an exchange rate volatility database 280, a payment 
database 2 85, an end- user account database 29 0, and 

15 cryptographic key database 295. In a preferred 
embodiment, database software such as Oracle7, 
manufactured by Oracle Corporation, creates and manages 
these databases. 

End-user database 255 maintains data about end 

20 users and, in one embodiment, includes fields such as 
name, address, credit card number, phone number, ID 
number, social security number, electronic mail address, 
and public/private key information. This information is 
preferably obtained when the end user first generates 

25 insurance policy 60 on the system. End-user database 255 
also contains the tracking number of each insurance policy 
60 generated by the end user. 

As shown in Fig. 2A, policy requirements 
database 2 60 maintains data on policy requirements 

30 generated by the end user, and preferably includes fields 
such as end-user ID, credit card number, currency 
selected, exchange rate, start date of coverage, end date 
of coverage, and amount of coverage, and policy 
requirements tracking number, 

35 As shown in Fig, 2B, insurance policy database 
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2 65 tracks each insurance policy 60 generated by end 
users, and preferably includes fields such as end-user ID 
number, insurance policy 60, tracking number, date 
generated, policy requirements tracking number, and status 
of premium payment. Each insurance policy 60 may have an 
5 associated status of insurance policy 60 such as "active, " 
"pending, " or "expired. " 

As shown in F±g . 2C, transaction data database 
270 stores all transaction data relating to insurance 
policy 60. This database is indexed by the tracking 
10 number of insurance policy 60, and preferably contains 

fields such as end-user ID number, amount of transaction, 
date of transaction, prevailing exchange rate, and bank ID 
number . 

Exchange rate database 275 facilitates the 
15 processing of transaction data 70 by storing current and 
historic exchange rates for every country. The current 
exchange rate may be updated hourly or continuously, but 
preferably automatically via financial networks 
transacting interbank foreign exchanges. 
20 Exchange rate volatility database 2 80 stores 

historical volatility data corresponding to each currency. 
This data may include past exchange rates, as well as the 
standard deviation of the rates over a given period of 
time . 

25 Payment database 2 85 tracks premium payments by 

end users, payments to merchants or banks, and payment of 
claims for insurance policy 60, which contains fields such 
as end -user name, end -user ID number, credit card number, 
amount of payment, and date of payment. This database may 

30 also store the user's bank account information. 

End-user account database 290 allows central 
controller 200 to track amounts owed to the end user under 
claims against insurance policy 60. 

Finally, cryptographic key database 295 contains 

35 algorithms and keys for encrypting, decrypting, and 
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authenticating communications . 

Network interface 245 provides the gateway to 
communication with transaction networks and financial data 
providers supplying current exchange rate information. 
Conventional internal or external modems may serve as 
5 network interface 245. Network interface 245 preferably 
supports modems at a range of baud rates from 12 00bps 
upward, but may combine such inputs into a Tl or T3 line 
if more bandwidth is required. In a preferred embodiment, 
network interface 245 is connected with the Internet or 

10 private data network. 

IVRU 225 allows end users to communicate with 
central controller 2 00 via telephone. The user can 
therefore enter policy requirements 50 via touch- tone keys 
of the end user's telephone. 

15 In another embodiment, central controller 200 is 

configured in a distributed architecture, wherein the 
databases and processors are housed in separate units or 
locations. Some controllers perform primary processing 
functions and contain at a minimum, a RAM, a ROM, and a 

20 general processor. Each of these controllers is attached 
to a wide -area network (WAN) hub that serves as a primary 
communication link with the other controllers and 
terminals. The WAN hub may have minimal processing 
capability itself, serving primarily as a communications 

25 router. 

In an exemplary embodiment, end-user interface 
3 00 is a conventional telephone, capable of communicating 
with central controller 200 via a public switched 
telephone network. Conventional cellular phones or PCS 

30 devices would work equally well. 

Alternatively, end-user interface 300 includes a 
conventional personal computer having an input device, 
such as a keyboard, a mouse, or a conventional voice 
recognition software package; a display device, such as a 

35 video monitor; a processing device, such as a CPU; and a 
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network interface, such as a modem. This configuration 
allows the end user to communicate with central controller 
200 using any one of commercial on-line services such as 
America Online, CompuServe, or Prodigy, allowing end user 
access to central controller 200 from a wide range of 
5 electronic connections. 

Communications from end-user interface 300 are 
preferably software driven. Many commercial software 
applications, whose primary functions are message creation 
and transmission, can facilitate communications of 

10 end-user interface 300. Eudora Pro manufactured by 

Qualcomm Incorporated, for example, provides editing tools 
to create messages as well as communications tools to 
route messages to the appropriate electronic address. If 
central controller 200 is configured as a Web server, 

15 conventional communications software, such as Navigator® 
from Netscape Corporation may also be used. The end user 
may use Netscape's Navigator* browser to transmit policy 
requirements 50. Transaction interface 400 transmits 
transaction data 70 from the end user to central 

20 controller 200 for processing. The structure of 
transaction interface 400 depends on the type of 
transactions . 

Figs. 3-5 illustrate three different ways of 
further implementing the system in Fig. 1. Fig. 3 

25 illustrates a credit card implementation of the present 
invention. Transaction data 70 flows from a credit card 
reader 410, to a credit card processing network 420, then 
to a credit card clearinghouse 430, and finally to central 
controller 200. These transactions are described in more 

30 detail below in connection with Figs. 6-12. 

Fig. 4 illustrates an automated teller machine 
(ATM) implementation of the present invention in which the 
end user withdraws money from an ATM. In this embodiment, 
the end user enters transaction data 70 into an ATM 440, 

35 which then transmits the data to an ATM network 450, and 
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finally to central controller 200, This embodiment is 
described in more detail in connection with Figs. 13-15. 

Fig. 5 illustrates a bank implementation of the 
present invention in which the end user seeks to exchange 
currency at a bank or other financial institution. After 
5 providing transaction data 70 to a bank 460, bank 460 

relays the information to central controller 200 using a 
conventional telephone or electronic network. This 
embodiment is described in more detail in connection with 
Figs. 16 and 17. 

10 Credit Card Implementation 

In the credit card embodiment of the present 
invention shown in Fig, 3, policy requirements 50 and 
insurance policy 60 are transmitted over a phone line, 
while insured transactions occur through the use of a 

15 conventional credit card. 

Fig. 6 illustrates a preferred process for the 
end user to select policy requirements 50 (Fig. 1) . 
Policy requirements 5 0 describe parameters for insurance 
policy 60, and reflect the insurance needs of the end 

20 user. Initially, the end user calls central controller 
2 00 using a conventional telephone, establishing a 
communication link through a public switched telephone 
network (step 600) . The end user may speak to an operator 
or enter the information into IVRU 225. 

25 Central controller 200 processes information 

provided in steps 610 through 660 described below, as 
policy requirements 50. First, the end user provides his 
or her name or a unique ID number (step 610) . Central 
controller 200 either receives this ID number from the end 

30 user, or assigns a number to the end user. Central 

controller 2 00 maintains a database of end user ID numbers 
in end-user database 255, and assigns (or allows) only 
unique numbers. If minimal security is required, the 
user's telephone number may se2rve as the ID number since 

35 it is unique and easy to remember. If additional security 
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is required, authentication procedures, described 
hereinafter in the cryptographic authentication section 
may be implemented* 

The end user provides a credit card number 
designated under insurance policy 60 (step 620) , and then 
^ selects the foreign currency for insurance coverage, such 
as the French Franc or German Deutchmark (step 630) . For 
alternative implementations, the credit card number of 
step 62 0 may be replaced with any other financial account 
numbers of the end user. For some currencies, additional 

10 information is necessary to indicate which of several 

exchange rates apply. In some countries, for example, the 
exchange rate is more favorable for local residents than 
for tourists* 

The end user then selects the "locked- in" 

15 exchange rate (step 640) . For example, if the current 

market rate for French Francs is five per dollar, the end 
user may select five to one as his insured exchange rate. 
The end user may lock in at any rate and the premium cost 
is computed accordingly. Insurance policy 60 will later 

20 compensate the end user for any transaction executed 

during a coverage period if the prevailing exchange rate 
at the time of transaction is less favorable than the 
locked- in exchange rate of five French Francs per dollar. 
This protects the end user against an unfavorable 

25 fluctuation of currency exchange rate. 

Next, the end user selects start and end dates 
of coverage (step 650) . These dates may correspond with 
personal or business travel dates of the end user. 
Transactions occurring either before the start date or 

30 after the end date are not covered by insurance policy. 

For example, policy requirement 50 of a business traveler 
on a two week trip may require a start date of July 5, 
1996 and an end date of July 19, 1996. The end user also 
selects the desired amount of coverage, preferably in 

35 domestic currency. 
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In the above example, the end user selects two 
thousand dollars of coverage, ensuring protection for two 
thousand dollars' worth of transactions at the locked- in 
rate. Transactions may, for example, include credit card 
payments for hotels and restaurants. After spending 
^ Francs equivalent of two thousand dollars at the locked- in 
rate, the end user is subject to the prevailing exchange 
rate and no longer enjoys the locked- in rate for future 
transactions . 

Fig. 7 is a flowchart illustrating a preferred 

10 process for calculating a premium cost. First, central 

controller 200 stores policy requirements 50 received from 
the end user, along with the end-user ID number, in policy 
requirements database 260 (step 700) , CPU 205 accesses 
exchange rate database 2 75 for the current exchange rate 

15 of the currency designated in policy requirements 50 (step 
710) . This exchange rate is preferably the current 
interbank rate, which serves as the basis of most global 
foreign exchange transactions. CPU 205 then accesses 
exchange rate volatility database 280 for exchange rate 

20 volatility data (step 720) . Currencies with large 

volatilities, expressed in terms of standard deviations 
over a fixed period of time, require a large premium cost 
due to a greater risk of exchange rate fluctuation. 

A premium cost is calculated based on policy 

25 requirements 50, the current exchange rate, and exchange 

rate volatility data (step 730) . Therefore, insurance for 
more volatile currencies requires higher premiums. Also, 
a coverage period having a start date far from the current 
date will also necessitate a higher premium as the effect 

30 of volatility is magnified over long periods of time. For 
example, policy requirements 50, indicating two days of 
coverage beginning five days from today, has a lower 
premium than the same policy beginning sixty days from 
now. Additionally, a longer coverage period requires a 

35 higher premium. The premium is also directly related to 



wo 98/21680 



PCT/US97/20754 



- 14 - 

o 

the amount of coverage. Policy requirements 50 specifying 
a locked- in rate that is below current spot exchange 
rates, however, lowers premium cost because a greater 
amount of fluctuation may occur before the coverage begins 
to take effect, thus, reducing the risk to the policy 
^ provider. Therefore, the premium cost is a function of 
policy requirements 50, current exchange rate, and 
exchange rate volatility. Once calculated, the premium 
cost is transmitted to the end user (step 740) . 

Fig. 8 is a flowchart illustrating a preferred 

10 process for creating insurance policy 60. The end user 
evaluates the premium cost transmitted by central 
controller 200 to decide whether the premium is acceptable 
(step 800) . If the premium is not acceptable to the end 
user, the end user may develop new policy requirements 5 0 

15 (step 820) , For example, if the premium is too high, the 
user may lower the amount of coverage or change the period 
of coverage. Central controller 200 then calculates a new 
premium based on the modified policy requirements 5 0 (step 
825), as described in connection with Fig. 7. 

20 If the premium is acceptable to the end user 

(step 810) , the user transmits an acceptance to central 
controller 200, providing confirmation over the phone or 
other communication channels such as electronic mail, 
postal mail, or pager (step 830) . To bill the user for 

25 the premium, central controller 200 may directly debit the 
user's credit card account or send a separate bill to the 
user. Next, central controller 200 generates a tracking 
number and appends it to insurance policy 60 (step 840) , 
and transmits this tracking number to the end user as a 

30 confirmation of insurance policy 60 (step 850) . If the 
user desires, central controller 200 also transmits the 
details of insurance policy 60 to the end user. 

At this point, central controller 200 assigns a 
"pending" status to the newly created insurance policy 60 

35 (step 855) . Central controller 200 stores insurance 
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policy 60 in insurance policy database 265 along with its 
corresponding status (step 860) . Later, if the end user 
satisfies a credit approval process or pays the premium, 
central controller 200 changes the "pending" status of 
insurance policy 60 to an "active" status, 
5 Central controller 200 also performs maintenance 

checks to ensure that only active insurance policy 60 is 
stored in insurance policy database 2 65. Fig, 9 is a 
flowchart illustrating a preferred process for maintaining 
active insurance policy 60 (Fig. 1). First, central 

10 controller 200 makes periodic searches through insurance 
policy database 2 65, retrieving the end date of each 
insurance policy 6 0 as well as the credit card number 
(step 900) . CPU 205 compares the end date of policy 60 
with the current date (step 910) . 

15 If the current date is later then the end date 

of insurance policy 60, central controller 200 changes the 
status of insurance policy 60 to "expired" (step 920) . 
Database records for "expired" insurance policies 60 may 
be deleted from insurance policy database 2 65 once all 

20 claims have been settled with the end user or stored in an 
audit database for subsequent reference. Additionally, 
payment processor 230 checks to see whether the credit 
card number is still valid by contacting a credit card 
clearinghouse (step 930) . If the card number is no longer 

25 valid, the status of insurance policy 60 is changed to 
"expired" (step 940) . Otherwise, insurance policy 60 
maintenance process is complete (step 950) . 

Once an active insurance policy 6 0 is stored in 
insurance policy database 265, the end-user may execute 

30 transactions under insurance policy 60. Fig. 10 is a 

flowchart illustrating a preferred process for generating 
transaction data 70 (Fig. 3) . As the end user executes 
foreign currency transactions with the credit card, the 
data is transmitted to central controller 200 for 

35 processing. First, the end user makes a credit card 



wo 98/21680 



PCT/US97/20754 



- 16 - 

o 

purchase with the credit card designated in insurance 
policy 60 (step 1000) . For example, the end user buys a 
bottle of wine in France, providing the merchant the 
credit card data. The merchant sends transaction data 70, 
which is the credit card data and the purchase amount, to 
5 credit card processing network 420 (step 1010). 

The merchant may swipe the credit card through 
credit card reader 410 to extract credit card information 
from the magnetic strip on the back of the card, or use 
some equivalent resource. The merchant then enters the 

10 amount of the transaction into a numeric keypad of credit 
card reader 410. Credit card reader 410, connected to 
credit card processing network 420 over a dedicated 
communication line, electronically transmits transaction 
data 70, and sends transaction data 70 to credit card 

15 clearinghouse 430 (step 1020) . Credit card clearinghouse 
43 0, operated by the member banks, functions as a 
consolidator of credit card transactions, and sends 
transaction data 70 to central controller 200 in real time 
or in a batch process (step 1030) . 

20 After central controller 200 receives 

transaction data 70, it processes transaction data 70 
under insurance policy 60. Fig. 11 is a flowchart 
illustrating a preferred process for determining whether 
an insurance adjustment 80 (Fig. 3) is necessary. First, 

25 central controller 200 searches insurance policy database 
265 for the credit card number associated with each 
transaction data 70 received from credit card 
clearinghouse 430 (step 1100) . If the credit card number 
is not found in insurance policy database 265 (step 1110) , 

30 no insurance adjustment 80 is necessary because the end 
user does not have an active policy (step 1120) . 

If the credit card number is found in insurance 
policy database 265, the exchange rate associated with 
transaction data 70 is compared with the locked- in rate 

35 specified in insurance policy 60 (step 113 0) , The 
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exchange rate associated with transaction data 70 is the 
prevailing spot exchange rate at the time of the 
transaction. This prevailing exchange rate is retrieved 
from exchange rate database 270. CPU 205 calculates 
whether the locked- in rate is more favorable than the 
5 prevailing rate on the day of transaction (step 1140) . 
For example, if the locked- in rate is five Francs per 
dollar and the prevailing spot rate on the day of the 
transaction is six Francs per dollar, then the prevailing 
rate is more favorable. If the prevailing rate is more 

10 favorable than the locked- in rate, insurance adjustment 80 
is not necessary (step 1150) . 

If the rate received by the end user is less 
favorable than the locked- in rate, CPU 205 checks 
insurance policy database 2 65 to determine whether the 

15 coverage amount has already been used up (step 1160) . If 
the coverage has been used up, insurance adjustment 80 is 
not necessary (step 1170) . For example, insurance policy 
6 0 with a two thousand dollar coverage does not cover 
insurance adjustment 80 for any transaction beyond the two 

20 thousand dollars. If the coverage is not exhausted, 
insurance adjustment 80 is necessary (step 1180) . 

Fig. 12 is a flowchart illustrating a preferred 
process for calculating the amount of insurance adjustment 
80. First, central controller 200 calculates the amount 

25 of the transaction in domestic currency using the 

locked- in exchange rate (step 12 00) . For example, a 
traveler paying one thousand francs for a hotel room with 
a locked- in exchange rate of five francs per dollar would 
have a transaction amount of two hundred dollars. 

30 Next, central controller 2 00 calculates the 

transaction amount in domestic currency using the 
prevailing exchange rate on the day transaction data 70 is 
received by central controller 200. For example, if the 
prevailing exchange rate is four francs per dollar when 

35 the traveler pays for his hotel room, the cost in dollars 
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would be two hundred and fifty. The differential between 
the two amounts is determined by subtracting the 
transaction amount at the prevailing rate from the 
transaction amount at the locked-in rate (step 1220). In 
the above example, the differential is fifty dollars. 
5 This represents a loss to the traveler due to the drop in 
exchange rates from five francs to four francs per dollar. 

Finally, insurance adjustment 80 is determined 
by computing the differential corresponding to the 
remaining amount of coverage under insurance policy 60. 

10 For example, if the traveler has only one hundred dollars 
of coverage remaining, the differential of fifty dollars 
is halved to reflect that only half of the two hundred 
dollar purchase transaction is covered, and the end user 
is only entitled to insurance adjustment 80 of twenty five 

15 dollars. If the end user has a remaining coverage greater 
than the purchase amount at the locked-in rate, then 
insurance adjustment 8 0 is equal to the computed 
differential. Insurance adjustment 80 is transmitted to 
the issuing bank of the credit card (step 123 0) , or stored 

20 in end-user account database 290 for later processing 

until the coverage of insurance policy 60 expires or is 
used up. Insurance adjustment 8 0 appears as a credit on 
the monthly credit card statement of the end user (step 
1240) . Central controller 200 also updates the remaining 

25 amount of coverage in end-user account database 290 (step 
1250) . 

ATM Implementation 

The end user can also enjoy a locked-in exchange 
rate for cash withdrawals from ATMs abroad. The procedure 
30 establishing insurance policy 60 is identical to that 
described above in connection with Figs. 6-8. 

Fig. 13 is a flowchart illustrating a preferred 
process for generating transaction data 70 when the end 
user withdraws money from an ATM. The end user requests 
35 foreign currency from ATM 440 (step 1300) . Using the 
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numeric keypad of ATM 440, the end user enters the amount 
of the transaction (step 1310) . A traveler in France, for 
example, withdraws one thousand francs from ATM 440. If 
the user wants to use the locked- in rate of insurance 
policy 60, the traveler enters the tracking number of 
^ insurance policy 60 into ATM 440 (step 1320) . In addition 
to the amount of withdrawal and tracking number, 
transaction data 70 includes, for example, the end user's 
PIN number, the current date, and an ATM identification 
number, ATM 440 sends transaction data 70 to ATM network 

10 450 using the dedicated communication line of ATM 440, 
ATM network 450 relays transaction data 70 to central 
controller 200 for processing, waiting for a transmission 
from central controller 200 to provide the appropriate 
exchange rate (step 133 0) , 

15 To obtain the appropriate exchange rate, central 

controller 200 determines whether an insurance adjustment 
is necessary when the end user withdraws money from an 
ATM. Referring to Fig. 14, central controller 200 
searches insurance policy database 265 for the tracking 

20 number received from ATM network 45 0 (step 1400) , If 

central controller 200 does not find the tracking number 
in insurance policy database 265 (step 1410) , central 
controller 200 transmits a message to ATM network 450, 
instructing ATM 440 to issue the cash at the prevailing 

25 rate (step 1420) . 

If the tracking number is found, central 
controller 200 compares the prevailing exchange rate to 
the locked- in exchange rate of insurance policy 60 (step 
1430) . If the exchange rate specified in insurance policy 

30 6 0 is not more favorable than the prevailing rate (step 

1440) , ATM 440 is instructed (through ATM network 450) to 
pay the end user at the prevailing exchange rate (step 
1450) . This prevents the end user from invoking a claim 
under insurance policy 60 if the prevailing exchange rate 

35 is less favorable or equal to the prevailing rate. 
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If the locked- in exchange rate is more favorable 
than the prevailing rate, however, central controller 2 00 
accesses end- user account database 290 to check the 
remaining coverage amount (step 1460) . If the coverage 
has been exhausted, ATM 440 is once again instructed to 
^ pay the end user at the prevailing exchange rate (step 

1470) . If coverage remains, however, central controller 
200 determines that insurance adjustment 80 is necessary 
(step 1480) . 

After central controller 2 00 determines that 

10 insurance adjustment 80 is necessary, it calculates the 
amount of insurance adjustment 80 as shown in Fig. 15. 
First, central controller 200 determines the remaining 
amount of coverage (step 1500) . Central controller 200 
then calculates the foreign exchange differential. In 

15 doing so, central controller 200 calculates the amount to 
be withdrawn in dollars at the locked- in rate (step 1510) . 
The amount of withdrawal is also calculated in dollars 
using the prevailing rate at the time of the withdrawal. 
Central controller 2 00 obtains the amount of insurance 

20 adjustment 8 0 as described above in connection with Fig. 
14 (step 152 0) , and updates the remaining amount of 
coverage in end-user account database 290 (step 1530). 

Central controller 200 instructs ATM 440 to 
present the end user with currencies at the locked- in 

25 exchange rate of insurance policy 60 (step 1540) . In 
order to compensate the bank operating ATM 44 0 for the 
exchange rate loss associated with the transaction, 
central controller 200 electronically transfers the amount 
of currency equal to insurance adjustment 80 to the bank 

30 (step 1550) . 

In an alternative embodiment, the end user's 
bank transmits the electronic compensation to the bank 
operating ATM 440. Central controller 200 later 
reimburses the end user's bank for the amount of insurance 

35 ad j us tment 8 0 , 
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Bank Implementation 

In another embodiment of the present invention, 
the end user enjoys a locked- in exchange rate for currency- 
exchanges at a bank. The procedure establishing insurance 
policy 60 is described above in connection with Figs. 6-8. 
5 Fig. 16 is a flowchart illustrating a preferred 

process for generating transaction data 70 by the end user 
exchanging money at a bank. The end user requests 
currency exchange at a foreign bank (step 160 0) , and 
specifies the amount of transaction (step 1610) . For 
10 example, a tourist may exchange two hundred dollars into 
francs . 

The end user then provides the tracking number 
of insurance policy 60 (step 1620) , enabling bank 460 to 
verify the exchange rate that the end user demands. Next, 

15 bank 460 calls central controller 200 using a conventional 
telephone (step 1630) , and provides transaction data 70 
such as end user name, insurance policy 60 tracking 
number, amount of currency to be exchanged, current 
exchange rate, and a bank identification number. Bank 46 0 

20 enters transaction data 70 using a touch- tone telephone or 
by speaking with an agent (step 1640) . 

Fig. 17 is a flowchart illustrating a preferred 
process for determining whether insurance adjustment 8 0 is 
necessary. Central controller 200 processes transaction 

25 data 70. Central controller 200 searches insurance policy 
database 2 65 for the tracking number transmitted by bank 
460 (step 1700) . If central controller 200 does not find 
the tracking number in insurance policy database 265 (step 
1710) , central controller 200 instructs bank 460 to 

30 exchange the end user's money at the prevailing exchange 
rate (step 1720) . If the tracking number is found, then 
the exchange rate provided by bank 460 is compared to the 
locked- in exchange rate specified in insurance policy 60 
(step 1730). If the locked-in rate is not more favorable 

35 (step 1740) , then central controller 200 instructs bank 
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460 to exchange the end user's money at the prevailing 
exchange rate (step 1750). If the locked-in rate is more 
favorable, central controller 200 checks the remaining 
amount of coverage (step 1760). If no coverage remains, 
central controller 200 instructs bank 460 to exchange the 
5 end user's money at the prevailing exchange rate (step 
1770) . If the coverage is not exhausted, however, 
insurance adjustment 80 is required (step 1780) . Central 
controller 20 0 then calculates the amount of insurance 
adjustment 80 as described above in connection with Fig. 

10 15, and updates the remaining coverage amount in end user 
account 240. 
Offline Implementation 

All the implementations described above use 
transaction data 70 transmitted to central controller 200 

15 over electronic networks. The present invention, however, 
may also employ off-line methods for submitting 
transaction data 70. 

For example, a business traveler on a two week 
trip in Germany could collect receipts for all of his 

20 transactions. Upon returning from the trip, the traveler 
may mail these receipts to a person who enters the data 
into central controller 200, which then processes the 
transaction as described above. Any insurance adjustment 
8 0 required may be mailed to the end user. 

25 Internet Implementation 

Creation of insurance policy 60 and processing 
of transaction data 70 can also take place over an 
electronic network such as the Internet or a commercial 
online service provider like America Online or CompuServe. 

30 The end user logs on to central controller 200 using a 
personal computer as end-user interface 300. The 
procedure establishing insurance policy 60 is similar to 
that described above in connection with Figs. 6-8. The 
end user is then able to provide the tracking number as 

35 proof of insurance for any electronic commerce conducted 
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on the Internet. 

For example, the end user accesses a Web site 
and purchases tickets (denominated in French francs) for 
an opera in France. The end user provides the credit card 
number and the tracking number, and the Web site verifies 
5 insurance policy 60 with central controller 200. Once 
verified, the Web site provides the tickets at the 
locked- in rate specified by insurance policy 60 and 
receives compensation from central controller 200 for the 
amount of insurance adjustment 80. 

10 Insurance policy 60 tracking number can also be 

used in the conversion of digital cash from one currency 
to another. The end user provides a quantity of digital 
cash to be converted along with the tracking number of 
insurance policy 60 to an online bank offering foreign 

15 exchange. The bank verifies the validity of insurance 

policy 60 with central controller 200, and accesses the 
locked- in exchange rate of insurance policy 60. Assuming 
the locked- in rate is more favorable and sufficient amount 
of coverage remains, the bank completes the conversion of 

20 funds at the locked- in exchange rate, electronically 

transferring the new currency back to the end user for 
storage at end-user interface 300. 

Alternatively, this digital money could be 
transferred to a stored value card, such as a smart card, 

25 so the end- user can use the money for transactions away 

from end-user interface 300. The practice of using digital 
cash protocols to affect payment is well known in the art 
and need not be described here in detail. For reference, 
one of ordinary skill in the art may refer to Daniel C. 

30 Lynch and Leslie Lundquist, Dicrital Money, John Wiley & 
Sons (1996) ; or Seth Godin, Presenting Digital Cash 
(1995) . 

Central controller 200 can also create a digital 
code incorporating all of the information in insurance 
35 policy 60. This digital code is encrypted with a private 
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key of central controller 200 and transmitted to the end 
user. The end user presents this digital code to a bank 
along with a request for currency exchange. The bank 
decrypts the digital code with the public key of central 
controller 200 and extracts all of the details of 
^ insurance policy 60, allowing the bank access to the 

locked- in exchange rate without having to contact central 
controller 200. The bank is assured that the digital code 
is legitimate because only central controller 2 00 has 
access to the private key that originally encrypted the 

10 digital code. 

This digital code may also be stored in a smart 
card. In that case, the end user need only swipe the card 
through a smart card reader to provide the digital code. 
Cryptographic Authentication 

15 The system can also provide additional security 

measures to ensure the integrity of data communications. 
One protocol is authenticating authorship of end user 
communications, i.e., checking an attached ID or name and 
comparing it with those stored in end-user database 255. 

20 Additionally, cryptographic protocols may be added to the 
authentication process. These protocols enhance the 
ability to authenticate the sender of a message and verify 
the integrity of the communication itself, proving that it 
has not been altered during transmission. Encryption can 

25 also prevent eavesdroppers from learning the contents of 
the communication. Such techniques shall be referred 
generally as cryptographic assurance methods and will 
include the use of both symmetric and asymmetric keys as 
well as digital signatures and hash algorithms. 

30 The practice of using cryptographic protocols to 

ensure the authenticity of senders as well as the 
integrity of communications is well known in the art and 
need not be described here in detail. Any conventional 
cryptographic protocols such as those described in Bruce 

35 Schneier, Applied Cryptography, Protocols. Algorithms, and 
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Source Code In C (2d ed. 1996) , could be used in 
accordance with the present invention. 

Fig. 18 is a flowchart illustrating an exemplary- 
authentication procedure using symmetric key protocols in 
which the end user and central controller 2 00 share a key. 
5 Thus, both encryption and decryption of end user 

communications are performed with the same key. This 
encryption may be implemented with an algorithm such as 
DES (U.S. Government standard, specified in FIPS PUB 46), 
or with any of several algorithms known in the art such as 

10 IDEA, Blowfish, RC4, RC2 , and SAFER. 

The end user encrypts communications with an 
assigned symmetric key (step 1800) , using cryptographic 
processor 210 of end-user interface 300. The end user 
communication is then transmitted to cryptographic 

15 processor 210 of central controller 200 (step 1810) . 

Cryptographic processor 210 extracts the end-user ID from 
the end-user communication (step 1820) , looks up the 
symmetric key of the end user in cryptographic key 
database 295 (step 1830) , and decrypts end-user 

20 communications with this key (step 1840) . Cryptographic 
key database 295 contains algorithms and keys for 
encrypting, decrypting and/or authenticating 
communications. If the resulting communication is 
intelligible, then it is determined to have been encrypted 

25 by the same key, thus authenticating the end user as the 
author of the message (step 1850) . 

This procedure makes it difficult for 
unauthorized end users to represent themselves as 
legitimate end users. Without cryptographic procedures, 

30 an unauthorized end user who obtained a sample 

communication from a legitimate end user may be able to 
extract the end-user ID and then attach this ID number to 
unauthorized communications. When end user communications 
are encrypted with a symmetric key, however, an 

35 unauthorized end user obtaining a sample end user 
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conimunication only discovers the end user's ID number, not 
the symmetric key. Without this key, the unauthorized end 
user cannot create an end-user communication that will 
fool central controller 200, since the unauthorized end 
user cannot encrypt the communication the same way as the 
5 authorized end user. The symmetric key protocol also 
ensures that the end-user communication has not been 
tampered with during transmission because alteration of 
the communication requires knowledge of the symmetric key. 
An encrypted end-user communication provides the end user 

10 with greater anonymity. 

Fig. 19 is a flowchart illustrating an exemplary 
asymmetric key protocol in which the end-user 
communication is encrypted with a private key and 
decrypted with a public key. Two such algorithms for 

15 asymmetric key protocols are RSA and DSA. The end user 
encrypts the communication with a private key using the 
cryptographic processor of end-user interface 300 (step 
19 00) , and transmits communication to central controller 
200 (step 1910) . Cryptographic processor 210 extracts the 

20 end-user ID (step 1920), and looks up the end user's 

associated public key in cryptographic key database 295 
(step 1930) , and decrypts the communication with this 
public key (step 1940) . As before, if the communication 
is intelligible then central controller 200 has 

25 authenticated the end user (step 1950) . Again, 

unauthorized end users obtaining the communication before 
it is received by central controller 200 are unable to 
alter it undetectably since the intruders do not know the 
private key of the end user. Unauthorized end users may, 

30 however, be able to read the message if they obtain the 
public key of the end user. Communication secrecy is 
preserved if the end user encrypts the communication with 
the public key, requiring the intruder to know the end 
user's private key to view the communication. 

35 CONCLUSION 
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The present invention provides foreign exchange 
insurance policies to individuals as well as large 
corporate entities and offers protection against 
unpredictable foreign exchange rate fluctuations. 
Additionally, the present invention provides a way of 
5 automatically processing transactions covered by the 
foreign exchange insurance policies. 

It will be apparent to those skilled in the art 
that various modifications and variations can be made in 
the present invention and in construction of the invention 

10 without departing from the scope or spirit of the 

invention. Other embodiments of the invention will be 
apparent to those skilled in the art from consideration of 
the specification and practice of the invention disclosed 
herein. The specification and examples should be 

15 considered as exemplary only, with the true scope and 

spirit of the invention indicated by the following claims. 
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WHAT IS CLAIMED IS : 

1. A method of providing a foreign exchange 

insurance policy comprising the steps, performed by a data 
processor, of: 

receiving from a user policy requirements for 
^ the foreign exchange insurance policy, the policy 
requirements including a user ID; 

storing the policy requirements and the 
corresponding user ID; 

accessing data corresponding to the specified 
10 currency and current market conditions; 

estimating currency volatility from the accessed 

data; and 

determining a premium cost based on the currency 
volatility. 

15 2 . The method of claim 1 further including the step 

of 

issuing a tracking code for the foreign exchange 
insurance policy. 

3 . The method of claim 2 further including the step 
20 of 

storing the tracking code corresponding to the 

user ID. 

4 . The method of claim 2 wherein the step of 
issuing a tracking code includes the substep of 

25 issuing the tracking code with the policy requirements. 

5 . The method of claim 4 wherein the step of 
issuing the tracking code includes the step of 

encrypting the tracking code. 

6 . The method of claim 1 including the step of 
30 transmitting the premium cost to the user. 

7. The method of claim 6 including the step of 
receiving from the user a confirmation to 

purchase the foreign exchange insurance policy. 

8. The method of claim 1 wherein the policy 

35 requirements further include a specified currency, an 
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exchange rate, an amount of coverage, and a period of 
coverage, and wherein the determining step further 
includes the substep of 

determining the premium cost based on the 
policy requirements and the currency volatility* 
5 9 . The method of claim 1 wherein the step of 

accessing the data includes the substep of 

accessing historic exchange rates. 

10. The method of claim 1 further including the 
steps of 

10 accessing a period of coverage of the foreign 

exchange insurance policies, and 

determining whether the period of coverage has 

expired. 

11. The method of claim 8 further including the step 
15 of 

updating the status of the foreign exchange 
insurance policies having an expired coverage period. 

12 . The method of claim 1 wherein the step of 
receiving the policy requirement includes the substep of 

20 receiving a credit card number as the user ID. 

13. The method of claim 1 wherein the receiving step 
includes the substep of 

authenticating the identity of the user. 

14. The method of claim 1 wherein the receiving step 
25 includes the substeps of 

receiving encrypted user policy requirements, 

and 

decrypting the encrypted user policy 
requirements . 

30 15 . A method of processing a foreign currency 

transaction under a foreign exchange insurance policy 
comprising the steps, performed by a data processor, of: 

receiving transaction data including a user ID, 
a transaction amount, and a transaction date; 

35 accessing a foreign exchange rate corresponding 
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to the transaction date; 

accessing a policy exchange rate corresponding 
to the user ID; 

comparing the foreign exchange rate of the 
transaction date with the policy exchange rate; and 
5 determining the amount of insurance adjustment 

using the transaction data and the compared exchange 
rates • 

16, The method of claim 15 including the step of 

verifying the validity of the user ID. 
10 17, The method of claim 15 including the step of 

crediting a user's account by the amount of the determined 
insurance adjustment. 

18. The method of claim 17 wherein the crediting 
step includes the substeps of 

15 accessing a remaining amount of coverage, and 

determining whether the remaining amount of 
coverage exceeds the transaction amount. 

19 . The method of claim 15 wherein the receiving 
step includes the substep of 

20 receiving the transaction data from an automatic 

teller machine. 

20. The method of claim 15 wherein the receiving 
step includes the substep of 

receiving the transaction data from a bank 

25 terminal . 

21. The method of claim 15 wherein the receiving 
step includes the substep of 

receiving the transaction data from a server on 
a computer network. 
30 22 , A method of processing a foreign currency credit 

card transaction under a foreign exchange insurance policy 
comprising the steps, performed by a data processor, of: 

receiving transaction data including a user ID, 
a credit card number, transaction amount, and a 
35 transaction date; 
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verifying the validity of the credit card 

numbers- 
accessing a foreign exchange rate corresponding 

to the transaction date; 

accessing a policy exchange rate corresponding 
^ to the user IDs- 
comparing the foreign exchange rate of the 

transaction date with the policy exchange rate; and 

determining the amount of insurance adjustment 

using the transaction data and the compared exchange 
10 rates . 

23. The method of claim 22 including the step of 

crediting a user's credit card account 
corresponding to the verified credit card number by the 
amount of insurance adjustment. 
15 24. The method of claim 23 wherein the crediting 

step includes the substeps of 

accessing a remaining amount of coverage, and 

determining whether the remaining amount of 
coverage exceeds the transaction amount. 
20 25. The method of claim 22 wherein the accessing 

step further includes the substep of 

accessing the foreign exchange rate from an 
external source separate from the data processor. 
26. A method of controlling information transfer 

25 between a data processor and a central controller for a 
foreign exchange insurance policy comprising the steps, 
performed by the data processor, of: 

receiving from a user a transaction request; 

receiving from the user transaction data 
30 including a tracking number of the foreign exchange 
insurance policy; 

transmitting the transaction data to the central 
controller; 

receiving from the central controller 
35 instructions for processing the transaction request; and 
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processing the transaction request according to 
the received instructions. 

27. The method of claim 2 6 wherein the step of 
receiving transaction data includes the substep of 

receiving a user ID, a transaction amount, and a 
5 transaction date. 

28. The method of claim 2 6 wherein the step of 
receiving instructions includes the substep of 

receiving an appropriate currency exchange rate 
under the foreign exchange insurance policy. 
10 29. A method of controlling information transfer 

between an automatic teller machine (ATM) and a central 
controller for a foreign exchange insurance policy 
comprising the steps, performed by the ATM, of: 

receiving from a user a transaction request; 
15 receiving from the user transaction data 

including a tracking number of the foreign exchange 
insurance policy; 

transmitting the transaction data to the central 
controller; 

20 receiving from the central controller 

instructions for processing the transaction request; and 

processing the transaction request according to 
the received instructions. 

30. The method of claim 29 wherein the step of 
25 receiving transaction data includes the substep of 

receiving a user ID, a transaction amount, and a 
transaction date. 

31. The method of claim 29 wherein the step of 
receiving instructions includes the substep of 

30 receiving an appropriate currency exchange rate 

under the foreign exchange insurance policy. 

32. A system for providing a foreign exchange 
insurance policy comprising: 

means for receiving from a user policy 
35 requirements for the foreign exchange insurance policy. 
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the policy requirements including a user ID; 

a database storing the policy requirements and 
the corresponding user ID; 

means for accessing data corresponding to the 
specified currency and current market conditions; 
5 means for estimating currency volatility from 

the accessed data; and 

means for determining a premium cost based on 
the currency volatility. 

33. The system of claim 32 further including 

10 first issuing means for issuing a tracking code 

for the foreign exchange insurance policy. 

34. The system of claim 33 wherein the database 
further stores the tracking code corresponding to the user 
id. 

15 35. The system of claim 33 wherein the first issuing 

means includes 

second issuing means for issuing a tracking code 
with policy requirements. 

36. The system of claim 35 wherein the first issuing 
20 means includes 

means for encrypting the tracking code. 

37. The system of claim 32 further including means 
for transmitting the computed premium cost to the user. 

38. The system of claim 3 7 further including means 
25 for receiving from the user a confirmation to purchase the 

foreign exchange insurance policy. 

39. The system of claim 32 wherein the policy 
requirements further include a specified currency, 
exchange rate, amount of coverage, and a period of 

30 coverage, and wherein the determining means further 
includes 

means for determining the premium cost based on 
the policy requirements and the currency volatility. 

40. The system of claim 32 wherein the accessing 
35 means further include 
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means for accessing historic exchange rates • 

41. The system of claim 32 further including means 
for accessing from the database the period of coverage of 
the foreign exchange insurance policies, and 

means for determining whether the period of 
5 coverage has expired, 

42. The system of claim 41 further including means 
for updating the status of the foreign exchange insurance 
policies having an expired coverage period. 

43 . The system of claim 32 wherein the receiving 
10 means includes 

means for receiving a credit card number as the 

user ID, 

44. The system of claim 32 wherein the receiving 
means includes 

15 means for authenticating the identity of the 

user . 

45. The system of claim 32 wherein the receiving 
means includes 

means for receiving encrypted user policy 
20 requirements, and 

means for decrypting the encrypted user policy 
requirements . 

46. A system for processing a foreign currency 
transaction under a foreign exchange insurance policy 

25 comprising: 

means for receiving transaction data including a 
user id, a transaction amount, and a transaction date; 

first accessing means for accessing a foreign 
exchange rate corresponding to the transaction date; 
30 second accessing means for accessing a policy 

exchange rate corresponding to the user ID; 

means for comparing the foreign exchange rate of 
the transaction date with the policy exchange rate; and 

means for determining the amount of appropriate 
35 insurance adjustment using the transaction data and the 
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compared exchange rates . 

47. The system of claim 46 including 

means for verifying the validity of the user ID. 

48. The system of claim 46 including 

means for crediting the user's account by the 
^ amount of insurance adjustment. 

49. The system of claim 48 wherein the crediting 
means includes 

third accessing means for accessing a remaining 
amount of coverage, and 
10 means for determining whether the remaining 

amount of coverage exceeds the transaction amount. 

50. The system of claim 46 wherein the receiving 
means receives the transaction data from an automatic 
teller machine. 

15 51. The system of claim 46 wherein the receiving 

means receives the transaction data from a bank terminal. 
52. The system of claim 46 wherein the receiving 

means receives the transaction data from a server on a 
computer network. 

20 53. A system of processing a foreign currency credit 

card transaction under a foreign exchange insurance policy 
comprising : 

means for receiving transaction data including a 
user ID, a credit card number, a transaction amount, and a 
25 transaction date; 

means for verifying the validity of the credit 
card number; 

first accessing means for accessing a foreign 
exchange rate corresponding to the transaction date; 
30 second accessing means for accessing a policy 

exchange rate corresponding to the user ID; 

means for comparing the foreign exchange rate of 
the transaction date with the policy exchange rate; and 
means for determining the amount of insurance 
35 adjustment using the transaction data and the compared 
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exchange rates . 

54. The system of claim 53 including 

means for crediting the user's credit card 

account corresponding to the verified credit card number 

by the amount of insurance adjustment. 
5 55. The system of claim 54 wherein the crediting 

means includes 

third accessing means for accessing a remaining 

amount of coverage, and 

means for determining whether the remaining 
10 amount of coverage exceeds the transaction amount. 

56. The system of claim 53 wherein the first 
accessing means includes 

fourth accessing means for accessing the foreign 
exchange rate from an external source separate from the 
15 data processor. 

57. A system for controlling information transfer 
between the system and a central controller for a foreign 
exchange insurance policy comprising: 

first receiving means for receiving from a user 
20 a transaction request; 

second receiving means for receiving from the 
user transaction data including a tracking number of the 
foreign exchange insurance policy; 

means for transmitting the transaction data to 
25 the central controller; 

third receiving means for receiving from the 
central controller instructions for processing the 
transaction request; and 

means for processing the transaction request 
30 according to the received instructions. 

58. The system of claim 57 wherein the second 
receiving means includes 

fourth receiving means for receiving a user ID, 
a transaction amount, and a transaction date. 
35 59. The system of claim 57 wherein the third 
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receiving means includes 

fifth receiving means for receiving an 
appropriate currency exchange rate under the foreign 
exchange insurance policy. 

60. An automatic teller machine (ATM) for 

5 controlling information transfer between the ATM and a 

central controller for a foreign exchange insurance policy 
comprising : 

first receiving means for receiving from a user 
a transaction request; 
10 second receiving means for receiving from the 

user transaction data including a tracking number of the 
foreign exchange insurance policy; 

means for transmitting the transaction data to 
the central controller; 
15 third receiving means for receiving from the 

central controller instructions for processing the 
transaction request; and 

means for processing the transaction request 
according to the received instructions. 
20 61. The system of claim 60 wherein the second 

receiving means includes 

fourth receiving means for receiving a user ID, 
a transaction amount, and a transaction date. 

62. The system of claim 60 wherein the third 
25 receiving means includes 

fifth receiving means for receiving an 
appropriate currency exchange rate under the foreign 
exchange insurance policy. 

63. A computer- readable medium for providing a 
30 foreign exchange insurance policy comprising: 

means for causing a data processor to receive 
from a user policy requirements for the foreign exchange 
insurance policy, the policy requirements including a user 
ID; 

35 means for causing a database to store the policy 
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requirements and the corresponding user ID; 

means for causing a data processor to access 
data corresponding to the specified currency and current 
market conditions ; 

means for causing a data processor to estimate 
5 currency volatility from the accessed data; and 

means for causing a data processor to determine 
a premium cost based on the currency volatility. 
64. An article of manufacture capable of configuring 

a data processor to perform a method of providing a 
10 foreign exchange insurance policy comprising the steps of: 

receiving from a user policy requirements for 
the foreign exchange insurance policy, the policy 
requirements including a user ID; 

storing the policy requirements and the 
15 corresponding user ID; 

accessing data corresponding to the specified 
currency and current market conditions; 

estimating currency volatility from the accessed 

data; and 

20 determining a premium cost based on the currency 

volatility . 
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